IBIS Macromodel Task Group Meeting date: 13 April 2021 Members (asterisk for those attending): Achronix Semiconductor * Hansel Dsilva ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: * Ambrish Varma Ken Willis Jared James Google: Zhiping Yang Intel: * Michael Mirmak Kinger Cai Alaeddin Aydiner Keysight Technologies: * Fangyi Rao Radek Biernacki * Ming Yan Todd Bermensolo * Rui Yang Luminous Computing * David Banas Marvell Steve Parker Micron Technology: * Randy Wolff * Justin Butterfield Missouri S&T Chulsoon Hwang Siemens EDA (Mentor): * Arpad Muranyi SiSoft (Mathworks): * Walter Katz Mike LaBonte Teraspeed Labs: * Bob Ross Zuken USA: * Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Hansel to submit his PAM4 Thresholds clarification BIRD, with the noted changes, to the Open Forum for potential inclusion in IBIS 7.1. - In progress. Hansel had prepared a new version to review today. - Walter to investigate whether any model vendors are generating legacy Tx models that optimize based on their downstream channel. - In progress. Walter reported that he'd reached out to one particular model maker (known to have generated 1 in the past) but hadn't heard back yet. - Walter to send out his new BIRD210 vs BIRD211 compromise presentation. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the April 6th meeting. Walter moved to approve the minutes. Randy seconded the motion. There were no objections. ------------- New Discussion: Clarification of PAM4 Thresholds: Hansel reviewed a new BIRD draft he'd created after last week's meeting. It augments the Usage Rules for the PAM4 Thresholds by adding the qualifier "zero voltage-centered": "... when the zero voltage-centered signal is sampled:" This version had been pared down to just the affected paragraph, as discussed in the previous meeting. Walter moved to recommend that Hansel submit this BIRD to the Open Forum and to note that ATM recommends that the BIRD be approved for inclusion in IBIS 7.1. Randy seconded. There were no objections. Arpad asked Hansel to send the BIRD to Randy so it could be submitted. Arpad asked Randy to note in his email announcing the BIRD that ATM recommended approving it for 7.1. BIRD210 and BIRD211: Fangyi shared a new "Combined Redriver Flow" presentation. He said that at the last ATM meeting, Walter and Arpad had suggested that it would be nice if the terminal (initial) Tx and terminal Rx worked the same way for regular channels and redriver channels. Fangyi had thought about a hybrid proposal to do just that. slide 2: Summary - Combine BIRD210 and BIRD211 so terminal Tx and Rx work the same way for regular channels and redriver channels - Utilize existing crosstalk columns in the impulse matrix to obtain the Tx and Rx filter impulse responses if necessary and avoid deconvolution (i.e., variations on the Dirac delta crosstalk column trick) - No new parameter necessary - Works with new and old models and mixes of the two - No change to regular channel flow Fangyi said with this proposed flow there would be no change to the regular channel flow, so no need to assume that the Tx model doesn't optimize based on the downstream channel. slide 3: Tx Init This slide shows block diagrams of the inputs and outputs to Tx Init under the current IBIS 7.0 flow and this new hybrid flow. For the Tx, the new flow is a modified version of the BIRD210 flow. The new flow preserves the legacy flow in the first 2 columns. It adds a third column, in which the EDA tool places the cumulative upstream response. Old models won't even know the new column is there. New models can utilize the information in the new column, but they must not modify it in case they're being used in an old flow (column wasn't provided by the tool). Old and new models handle the legacy columns as they've done in IBIS 7.0. The 4th column from the original BIRD210, in which the model returned its filter's response, is no longer there. Instead, the tool can use the Dirac delta in a crosstalk column as Walter had described. The Tx won't optimize based on crosstalk so this extra Dirac delta column wouldn't cause any problems. slide 4: Rx Init This slide shows block diagrams of the inputs and outputs to Rx Init under the current IBIS 7.0 flow and this new hybrid flow. For the Rx, the new flow is the same as the BIRD211 flow. For the Rx, the first column input is changed to the cumulative upstream response as opposed to the immediate upstream channel response. Both old and new models would modify the columns as in IBIS 7.0. The output of the first column (now cumulative upstream + Rx effects), can be used in the statistical flow and fixes the IBIS 7.0 Redriver statistical flow problem. For time domain simulation, an Rx with DFE must include a GetWave. Fangyi proposed a variation of the Dirac delta trick. He said the tool could pass in an epsilon*(Dirac_delta), with epsilon << 1. With this small epsilon, this crosstalk column would not affect the Rx Init's behavior even if it uses crosstalk information to optimize. The EDA tool could use what's returned in that column to recover the filter response. The EDA tool can use the Tx and Rx filter impulse responses it obtains to construct the impulse of any channel section and crosstalk path. slide 5: Current Flow Block diagram of the broken IBIS 7.0 Redriver statistical flow for both upstream and downstream channels. slide 6: Proposed New Flow Block diagram showing what the Tx1, Rx1, Tx2, and Rx2 can do with the new flow. - Tx1 and Rx1 follow the legacy flow. - Tx2 has the legacy columns and the new column for the cumulative upstream response if it wants it (doesn't modify the new column). - Rx2 get the full cumulative upstream response in column1, so the problem with the IBIS7.0 statistical Redriver flow is resolved. - Tx and Rx (LTI portion) equalization impulse responses can be used to avoid deconvolution and deal with crosstalk. slide 7: Notes - New flow supports new models, old models, and a mix of the two - No change requiring the assumption that Tx models don't optimize based on the downstream channel - No change to the regular channel flow - Terminal Tx and Rx work the same way for regular and redriver channels - New parameter not required. Arpad summarized the main points of the new flow: - Tx side is more like BIRD210 - Rx side is more like BIRD211 - Introduction of the epsilon scaling factor to the fictitious Dirac delta crosstalk column for the Rx. Ambrish asked how the Tx would know whether it had the new "upstream" column available? Walter concurred and said you tell the Tx the number of crosstalk victims, but how would it know if the extra column was there at the end? Fangyi said a new model would assume it's there. If a model needs the new column, it can't work in the old flow anyway. Arpad asked what the model would do if it were used in a simulator that didn't provide the new column (old flow)? How would it avoid trouble if there were garbage (no data) in that column? Fangyi said the model maker should provide that as documentation to the user, "this model needs the new flow". Walter said leaving it open and not telling the tool the model needed the new column was dangerous. He said he would insist on a new parameter to specify whether the new column was used or not. Walter said he didn't like the fact that the tool is obligated to provide that extra column all the time, whether the Tx needs it or not. Walter noted that he had sent out a BIRD211.1 draft to ATM, which had added a new optional column for the model to return the filter response. However, he said he was happy to forget about that and completely agreed with the Dirac delta approach. Walter said that he knew of no Redriver Tx models that optimized based on the downstream channel, and only one legacy initial Tx model that was created a long time ago that had tried to do it. He said we should not live with the baggage of a decision made 12 years ago to give the Tx the downstream channel IR. He said this was a decision that sounded reasonable at the time but had turned out to be a bad decision. Since only perhaps 1 Tx model had ever tried to do it, we should clean up the flow now and not live with the bad decision. Let's assume by default that the Tx does not optimize based on the downstream channel. It's a given that no Tx hardware does that. The only way a Tx can have its optimization changed by the downstream channel is in simulation or by a back-channel method. Walter said we should adopt a simple approach where any Tx always gets its cumulative upstream response in column 1. Then the Tx would behave just like the Rx in that regard. The statistical flow would then mirror the GetWave flow, which is how it should have been all along. Walter said we could then adopt BIRD211's new parameter and extra column in the rare cases where future Tx models will need the downstream information for optimization. Why add the complexity of an extra column when the vast majority of cases have no use for it? Fangyi said those new Tx models need two input columns, and it's just a matter of where the columns are located. Why not leave the existing columns alone and put the cumulative upstream information in a new column? Walter said every Tx should want the cumulative upstream data, so it makes more sense to put that in column 1 instead of adding it as the optional column. Then Txs and Rxs would be the same in terms of what they get as their column 1 input, and we add the special new parameter and new downstream response column only for the Tx2 models that need it. Walter said he doubted there was really a current legacy Tx model that would care if we changed the column 1 input to the Tx to be the cumulative upstream response. We're talking about 1 model that's probably obsolete and wasting our time and complicating the flow. If there were 100 affected legacy models, or even 10, maybe it would be worth the trouble, but there "might" be 1. Fangyi said doing that (putting the cumulative upstream info in column 1 for the Txs as well as the Rxs) would change the current flow, even for the regular non- Redriver channel. Walter said that it would give the exact same answer as the current flow, except in the case of Redrivers where it would fix the current flow and give the right answer. Walter said let's take the opportunity to make the statistical flow mirror the time-domain flow. Fangyi said this could break a legacy Tx. Walter said it would only break a Tx that optimized based on the downstream information it received in the legacy flow. He suggested the EDA tool could pass whatever it wants to the initial Tx. It could pass in the unit IR and convolve the output with the channel, or it could pass in the Tx's downstream channel's IR (legacy flow). Ambrish said the regular flow is fine, and the Redriver flow was an afterthought and is broken. He asked, why change more than we need to in an attempt to fix the Redriver flow? Why change the regular flow to fix the Redriver flow? Walter said we could do that - keep the primary Tx input the same, its downstream channel's IR. For the Redriver Tx we change the input to its upstream cumulative IR. Then we have a simple change as proposed in BIRD166 or BIRD211. Ambrish again emphasized that it's only the statistical flow for Redrivers that has a problem. The GetWave flow for Redrivers is fine. Walter agreed, "if" your GetWave can do all of the proper optimization in time-domain. Ambrish confirmed, yes, if your GetWave doesn't rely on Init. David asked if we have any plans to support non-linear photonic channels, meaning the channel itself is non-linear? Fangyi said you handle that by putting everything in the Redriver model's GetWave. David acknowledged, you collapse the entire channel into the Redriver model itself. PAMn BIRD: Michael asked if Walter's PAMn BIRD draft had been reviewed by ATM yet. Arpad said it had not. Walter confirmed that he does not consider it urgent or expect it to get into IBIS 7.1. He said he just wanted to get ATM to discuss whether we will go with a PAM3 BIRD or a more generalized PAMn approach, so they can start to develop models accordingly. Michael observed that the BIRD210/211 discussion is the largest remaining item for IBIS 7.1. - Walter: Motion to adjourn. - Michael: Second. - Arpad: Thank you all for joining. AR: Hansel to submit his PAM4 Thresholds clarification BIRD to the Open Forum. AR: Randy to note in his email announcing the new BIRD that ATM recommends it be approved for IBIS 7.1. AR: Fangyi to send his "Combined Redriver Flow" presentation to the ATM list. AR: Walter to investigate whether any model vendors are generating legacy Tx models that optimize based on their downstream channel. ------------- Next meeting: 20 April 2021 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives